home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 704 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.3 KB  |  100 lines
  1. Newsgroups: comp.lang.c
  2. Path: hpwin055.uksr!hpqmoea!neilg
  3. From: neilg@hpqt0319.sqf.hp.com (Neil Gall)
  4. Subject: Re: ugly constants and header files
  5. Sender: news@hpqmoea.sqf.hp.com (SQF News Admin)
  6. Message-ID: <DKvIKs.ACz@hpqmoea.sqf.hp.com>
  7. Date: Mon, 8 Jan 1996 17:43:40 GMT
  8. References: <k607w0zpkP3U088yn@merlin.magic.mb.ca>
  9. Nntp-Posting-Host: hpqt0319.sqf.hp.com
  10. Organization: Hewlett-Packard LTD, South Queensferry, Scotland
  11. X-Newsreader: TIN [version 1.1 PL8.8]
  12.  
  13. David C. Wright wrote:
  14.  
  15. > Create a single header file, of the form:
  16.  
  17.  [ stuff ]
  18.  
  19. > #ifdef GLOBALS
  20.  
  21. > int globalvar;
  22. > anystruct_t *ptr1;
  23. > enumvars_t evars;
  24.  
  25. > #else
  26.  
  27. > extern int globalvar;
  28. > extern anystruct_t *ptr1;
  29. > extern enumvars_t evars;
  30.  
  31. > #endif
  32.  
  33.  [ stuff ]
  34.  
  35. > #include this file in any modules that use the #defines/variables/prototypes
  36. > in question.  In *one* of the modules, use;
  37.  
  38. > #define GLOBALS
  39.  
  40. NO NO NO NO NO!!!  Aargh!  This is *really* horrible. Firstly, you've
  41. got two declarations for the same variables but the compiler isn't aware
  42. of the fact - if you change one and not the other by mistake you'll spend
  43. ages looking for that wierd bug.  In short it's a maintenance nightmare.
  44. Secondly, declaring variables in header files is generally considered to
  45. be pretty poor style.  I've seen this done so many times, sometimes
  46. disguised with some macros to avoid the double declaration problem, like
  47. this:
  48.  
  49.     #ifdef GLOBALS
  50.     #define variable
  51.     #else
  52.     #define variable extern
  53.     #endif
  54.  
  55.     variable int x;  etc...
  56.  
  57. This is just as ugly, and doesn't get away from the fact that variables
  58. are defined in header files, which (I'll say this again) is a pretty poor
  59. coding style and can be error prone.  What happens if you accidentally
  60. defined GLOBALS in another file ?  You'll get linker problems.
  61.  
  62. There is one simple, clean and effective way of doing this which will
  63. make your compiler complain if you do anything silly and which avoids
  64. all these problems:
  65.  
  66. Declare all the variables in a header file, say vars.h
  67.  
  68.     extern int globalvar;
  69.     extern anystruct_t *ptr1;
  70.     ...etc
  71.  
  72. And define them all in a source file, say vars.c, but remember to include
  73. vars.h.  This way you still define the variable in two places, but the
  74. compiler will barf if there is a mismatch.
  75.  
  76.     #include "vars.h"
  77.  
  78.     int globalvar = 1;
  79.     anystruct_t *ptr1 = NULL;
  80.  
  81. What all this boils down to is that C is absolutely pathetic at handling
  82. multiple source files.  In fact, since it relies on the preprocessor you
  83. could argue that C has no support at all for multiple source files. 
  84. Since using variables across multiple files is not very well supported
  85. in the language, all sorts of wierd and wonderful schemes have been
  86. designed to do it.  In my mind, what to think about when doing this is
  87. keeping the interface and the implementation of your modules separate.
  88. Keep the interface in .h files and the implementation in .c files.  This
  89. fits neatly into C's limitations.
  90.  
  91. What I want to see in the next standard is a better way of exporting
  92. module interfaces to other modules which can't be abused in the way that
  93. header files tend to be.
  94.  
  95. --
  96. |    Neil Gall, Hewlett-Packard Ltd, Queensferry Telecoms Operation,   |
  97. |          South Queensferry, Scotland  +44 (0)131 331 7112            |
  98. | neilg@hpsqf.sqf.hp.com    http:/www.tardis.ed.ac.uk/~chrism/neil/nb/ |
  99. |             "That's what it'll be like in the future..."             |
  100.